In the World Wide Web (WWW), service providers often offer their services through specific application programming interfaces (APIs) that are accessible via the Hypertext Transfer Protocol (HTTP). The services are executed on a remote system or server, hosting the requested service. Such APIs are referred to as web services. Orchestrated web services can be, for example, implemented in a loosely coupled architecture according to service-oriented architecture (SOA) principals. In a SOA-based implementation of orchestrated web services the basic unit of communication is a message, rather than an operation.
According to the SOA principals, web services comprise loosely coupled units of functionality that have no calls to each other embedded in them. Each service implements one action, such as filling out an online application for an account, or viewing an online bank statement, or placing an online booking or airline ticket order. The web services use defined protocols that describe how services pass and parse messages using description metadata. For example, the Web Services Description Language (WSDL) can be used to describe the web services themselves, while the Simple Object Access Protocol (SOAP) can describe communications protocols between web services.
Accessing a web service from an entity (e.g. a client application operated by a user) typically requires being compliant with security requirements. For example, before executing some requested functionality of a web service, a web server hosting the web service (aka web service provider) may need to check if the user is allowed to invoke the web service and/or the requested functionality. In other words, web services providers may authorize or not access to a web service and/or requested functionality. Granting a user access to a web service and/or related functionality is typically related to establishing a session between the client application operated by the user and the web service provider. During the session, the client application and the web service provider may exchange one or more messages in the same session without the need to grant access again as long as the session is active.
A session may relate to a semi-permanent interactive information interchange between two or more entities (including e.g. a server computer, a client computer hosting a client application, a communication device, etc.). A session may be set up or established at a certain point in time, and torn down at a later point in time. An established session may involve more than one message between the involved entities in each direction. When security requirements impose a web service interaction to set-up a session to enable client and server to exchange messages, client application has to implement all the logic and functionalities to manage set-up, renewal, expiration of a session. When a session is or has been established, it usually associated with a token (also referred to as a session token). Tokens or session tokens are the unique identifiers of the session and must be passed in the body of the messages as a form of “certificates” to exchange messages with the server inside the same session. In most web service implementations, session management is however often performed in a less optimized and rather inefficient manner. For example, by opening a new session for each message exchanged by each client invoking the web services. Indeed session management of the web server usually generates a new session token for a user each new session. Session management might be therefore inefficient with regard to processing resources such as time, memory, and/or performance, in particular, when a user is invoking and/or running a plurality of different sessions.
Consequently, there is a need to provide an efficient mechanism for managing user's session tokens for client applications interactions that can improve performance regarding time and/or memory consumptions